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reciprocal requirements of the parties. In practice, that will rarely happen and some 
sort of netting will be required. The exact details of the netting process, whilst 
outside of the scope of the present invention, are included here for clarity and 
completeness. 

The fundamental netting concept applied in this embodiment is that a computer is 
programmed with information relating to a party and counterparty transaction, to 
determine a net payment position if both the first and second transactions occur 
and to actually complete each transaction on the basis of the net payment position. 

This approach can be contrasted with conventional netting, in which a transaction is 
completed and only subsequently does netting occur to reduce the number and size 
of payments. Typically, there might be several party /counterparty pairs in a 
coimected series of transactions in the present embodiment. 

Multilateral Netting Example 

In the present system, it will be seen that the netting step is not simply a stage 
subsequent to but independent from the underlying exchange transaction, performed 
for accounting simplicity to reduce the numbers and sizes of cross-payments. 
Instead, it is an integral part of the underlying exchange transaction between party 
and counterparty. This is most clearly emphasised when considering a multi-party 
exchange of currencies. Take, for example, a situation in which there are 3 
Corporations - A, B and C . A has CAD and needs JPY; B has JPY and needs 
USD; C has USD and needs CAD. The exact needs are shown in Figure 2 A. A 
cannot satisfy its requirements in whole or in part by dealing with B exclusively. 
However, if C can be "linked" into the transaction, all three corporations can be 
satisfied to the value of the smallest available currency. 
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We assume that the mid-point of Interbank B/0 at a point in time is as follows: 
1.53675 CAD; 1 USD; 88.7755 YEN; (i.e. all numbers are relative to the USD base 
currency). 

The desired amounts indicated on Figure 2A reflect the mid-market value of the 
available currency. The post-match situation using this embodiment is shown on 
Figure 2B. 

It will be noted that the limiting factor in this match example was the availability of 
CAD for JPY. 

The embodiment uses a "currency link" to match partially or fiiUy the desired 
quantities of the match, A currency link is created using the source currency and the 
beneficiary (desired) currency for a series of transactions. Figure 2C illustrates a 
simple three-way currency link. 

Note, that if, for example, Party C wanted a currency other than AAA, say DDD, 

there would not be a currency link from which to synthesize a transaction. 

A link is therefore defined as (A to B; B to A); or (A to B; B to C; C to A); or (A to 

B; B to C; C to D; D to A) etc. A mathematical relationship at a point in time 

therefore exists between the currencies. Another example is A to C, B to A and C to 

B. 

The distinction from traditional netting programs is three-fold. First, netting in the 
present embodiment happens in real-time, not at a fixed point in time post 
transaction for various parties, none of which are necessarily the same from one 
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"link" to the next, and consequently, from one "match" (whole or partial) to the 
next. Second, the program is designed to seek out the "currency linking" in 
ascending order of the number of potential counter-parties. As complete matches 
occur (as in A above), the matched party drops out of the matrix. The program 
seeks out the next currency links based on a set of transactions rules to fulfill 
wholly or partially the next match. Third, traditional netting occurs on completion 
of a series of transactions. For example, if Party A is obligated to pay Party B three 
units of a currency and Party B is obligated to pay Party C three units of a 
currency, a netting transaction would have Party A pay Party C three imits of 
currency directly. In this embodiment, transactions are synthesized by matching 
source (available) currency to beneficiary (desired) currency requirements. As such 
the transaction could be deemed a "netting hybrid". 

The present system may be further understood with reference to Figures 3A and 
3B, which each show a schematic of the major elements in a foreign exchange 
matching system in accordance with the present invention. Figure 3A is an actual 
proposed architecture schematic for an FX embodiment prepared by Primix 
Solutions Inc; the embodiment is called 'Buy FX'. The functions of the major 
blocks in Figure 3A and 3B are the same and are as follows: the party and 
counterparty each interact with the foreign exchange matching system using their 
web browsers (1, 2), which communicate via the Internet 3 with a conventional 
Web cluster/firewall 4 cormected to an application server cluster 5 running Netscape 
Application Server, IBM WebSphere or BEA WebLogic. Cluster 5 is connected to 
a message bus 7, such as Active Works or Tibco. The message bus 7 is connected to 
a live data feed 6, which provides continuous and up to date pricing mformation. A 
Reuters or Bloomberg feed could be used. Message bus 7 is also connected to a mail 



